Signal upload optimization

ABSTRACT

Aspects of the technology described herein allocate limited computing resources, such as available bandwidth and battery power, to transferring the most urgent and important data from a client device to an online service. Client devices have enormous amounts of information about the user&#39;s activities that could be communicated to the service at any given time. However, the wireless transfer of information uses available battery power and can consume a user&#39;s data plan. The technology described herein uses a model to determine how often information should be sent to a service. The model can also determine what information to send. Different models can be implemented in different scenarios. The different models can include different weighting that will produce different decisions given the same inputs.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/357,172, filed Jun. 30, 2016, entitled “SIGNAL UPLOAD OPTIMIZATION,”the entirety of which is herein incorporated by reference.

BACKGROUND

Cloud-based services can utilize personal contextual information (e.g.,web browsing, location data, calendar entries, communication data)provided by client devices to enable various user experiences on theclient. For example, a service could analyze contextual data to providea notification regarding an upcoming trip, nearby friends, or otherinformation relevant to a user-experience. The transfer of contextualinformation uses available bandwidth and battery power when the deviceis not “plugged-in.” Much of the contextual information may not berelevant to an available user-experience.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Aspects of the technology described herein allocate limited computingresources, such as available bandwidth and battery power, totransferring the most urgent and important data from a client device toan online service. Many online services rely on contextual informationabout a user and/or a user device to provide a service to the user. Forexample, a traffic notification service needs to know the user'slocation to provide a commute estimate along with relevant trafficinformation. An online personal assistant may require calendarinformation and/or data from email to help the user complete one or moretasks on time.

Client devices have enormous amounts of information about the user'sactivities that could be communicated to the service at any given time.However, the wireless transfer of information uses available batterypower and can consume a user's data plan. The technology describedherein uses a model to determine how often information should be sent toa service. The model can also determine what information to send.Different models can be implemented in different scenarios. Thedifferent models can include different weighting that will producedifferent decisions given the same inputs. For example, in a “runninglate” scenario, location information may be communicated more frequentlyto help determine whether the user is back on schedule and to providetips/reminders that help the user recover. Similarly, an “on vacation”scenario may cause more information to be shared because the user'sactions and needs will be less predictable than if the user was in a“typical work day” scenario.

BRIEF DESCRIPTION OF THE DRAWINGS

The technology described herein is illustrated by way of example and notlimitation in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIG. 1 is a block diagram of an example operating environment suitablefor implementations of the present disclosure;

FIG. 2 is a diagram depicting an example computing architecture suitablefor implementing aspects of the present disclosure;

FIGS. 3-5 are flow diagrams showing additional exemplary methods ofsignal compaction, in accordance with an aspect of the technologydescribed herein;

FIG. 6 is a block diagram of an exemplary computing environment suitablefor use in implementing aspects of the technology described herein; and

DETAILED DESCRIPTION

The various technology described herein is set forth with sufficientspecificity to meet statutory requirements. However, the descriptionitself is not intended to limit the scope of this patent. Rather, theinventors have contemplated that the claimed subject matter might alsobe embodied in other ways, to include different steps or combinations ofsteps similar to the ones described in this document, in conjunctionwith other present or future technologies. Moreover, although the terms“step” and/or “block” may be used herein to connote different elementsof methods employed, the terms should not be interpreted as implying anyparticular order among or between various steps herein disclosed unlessand except when the order of individual steps is explicitly described.

Aspects of the technology described herein allocates limited computingresources, such as available bandwidth and battery power, totransferring the most urgent and important data from a client device toan online service. Many online services rely on contextual informationabout a user and/or a user device to provide a service to the user. Forexample, a traffic notification service needs to know the user'slocation to provide a commute estimate along with relevant trafficinformation. An online personal assistant may require calendarinformation and/or data from email to help the user complete one or moretasks on time.

Client devices have enormous amounts of information about the user'sactivities that could be communicated to the service at any given time.However, the wireless transfer of information uses available batterypower and can consume a user's data plan. The technology describedherein uses a model to determine how often information should be sent toa service. The model can also determine what information to send.Different models can be implemented in different scenarios. Thedifferent models can include different weighting that will producedifferent decisions given the same inputs. For example, in a “runninglate” scenario, location information may be communicated more frequentlyto help determine whether the user is back on schedule and to providetips/reminders that help the user recover. Similarly, an “on vacation”scenario may cause more information to be shared because the user'sactions and needs will be less predictable than if the user was in a“typical work day” scenario.

The technology described herein may use contextual signals to determinewhether the same contextual signals or other contextual signals shouldbe communicated. “Contextual signals,” as utilized herein, may reflectany attribute of a user (for instance, physical characteristics), theuser's historical interaction with the system (e.g., behavior, habits,and system interaction patterns), and/or the user's recent interactionwith the system (with “recency” being defined in accordance with apredetermined time frame relative to a given point in time) that mayaffect the likelihood or probability that the user desires to engagewith a particular computer application or computer program. Suchcontextual signals may include, by way of example only and notlimitation, the location of the user of the computing device (determinedutilizing, for instance, Global Positioning System (GPS) signals,Internet Protocol (IP) address, or the like), the time of day (eithergeneral (for instance, morning or afternoon) or exact (for instance,6:00 pm)), the date (either exact or a particular month, season, etc.),a physical characteristic of the user (for instance, if the user isparalyzed and capable of only voice input, or the like), a taskcurrently engaged in on the computing device by the user, a taskrecently engaged in on the computing device by the user (again with“recency” being defined in accordance with a predetermined time framerelative to a given point in time), an object the user is currentlyengaged with on the computing device (for instance, an entity such as acontact, a file, an image, or the like), an object the user was recentlyengaged with on the computing device, a function currently beingperformed by the user on the computing device, a function recentlyperformed by the user on the computing device, hardware currently beingutilized on the computing device, hardware recently utilized on thecomputing device, software currently being utilized on the computingdevice, and software recently utilized on the computing device. Thecontextual signals can also include calendar entries, emails, texts,social network interactions and communications, and derivatives or metadata from all of the above. An example derivative could be a snippetfrom an email that describes an upcoming meeting, instead of the entireemail. Another example could be a conclusion drawn from the email, suchas Bob will late to the meeting.

While contextual data of all sorts may be described as being transferredbetween the client device and one or more online services, it should benoted that all such transfers may be subject to various privacy policiesthe user has been made aware of and either agreed to or opted out of.Aspects the technology described herein are not dependent ontransferring or having the ability to transfer all the different typesof information described. Privacy policies and other considerations canbe implemented to define what types of information the technologydescribed herein can share. It should also be noted, that the onlineservice can take steps, not described herein, to protect any datareceived.

In one aspect, user data is transmitted with a default frequency anddefault content definition absent other determinations that adjust thedefault frequency and definition. The frequency of transmission defineshow often transmissions occur. The content definition is used to selectcontent for transmission given the context. A series of determinationscan be made to adjust the default settings to scenario specificsettings. The determinations can cause adjustments in isolation or incombination. In one aspect, the determinations have a hierarchy thatallows some determinations to override or influence others.

In one aspect, the first determination is a device contextdetermination. The device context could be assigned a profile defined byvarious device characteristics. For example, a series of profiles may berelevant when the client device is running on battery power. Differentprofiles can be based on different levels of energy remaining in thebattery. Another set of profiles, could be based on whether an activedata link over which user data will be transmitted has a data quota.More granular profiles could be based on an amount of data left in thequota. As an example, when a device context profile that is associatedwith a reduced frequency of transmission is active, the defaultfrequency of user data transmission will be reduced to what can bedescribed as a device-context-specific transmission rate. The contentdefinition could be adjusted in a similar fashion to transmit lesscontent with each transmission. The definition is adjusted to make surethe most important or urgent user data is transmitted.

A second determination can be based on user context. As an example, auser context could indicate that the user is out of routine. When theuser is out of routine, one or more services enabled by the provision ofuser data could be of significant benefit to the user. As with thedevice context, user data can be evaluated to assign a user contextprofile to the user at a point in time. The profile can dictate whetherthe active transmission frequency is increased or decreased. Theincrease or decrease can be by a discrete amount or percentage.

When a first determination and a second determination are combined thefinal transmission frequency could be influenced by both. In anotheraspect, a determination resets the transmission frequency and contentdefinition according to a rule without regard to other determinations.

In one aspect, scenario specific models can be used adjust the frequencyof transmission and the content definition. A regular model can be usedwhen no scenario specific model is activated. Whether the regular modelor various scenario-specific models is active, can result in differenttransmission frequencies and content transmissions. For example, ascenario specific model related to a user running late for an eventcould result in more frequent transmission of data than the regularmodel.

In aspects, the content definition can be adjusted according to anexpected gain sharing certain user information with a service will haveto the user. Various services can be enabled when information is sharedwith them. The gain can be based on whether the user is likely to valuea service that could be provided and the impact information will have onthe quality of the service provided. The likely value a service couldhave to a user can be determined by a user's previous interactions oruse of that specific service. If the user's interactions indicate thatthe service is appreciated by the user, for example, responding directlyto communications related to the service, such as a task reminder, thenthe service could be deemed valuable. On the other hand, ifcommunications related to the service are routinely ignored then theservice may be deemed to have a low value to the particular user.

The value a specific piece of information has to the service can bedetermined by comparing a type of information the service needs with theamount of information of that type that the service currently possesses.A high-value could be placed on information of a type if the servicecurrently has little or no information of the type. High-value couldalso be placed on the information if the new information issignificantly different from previous information of the same type sentto the service. For example, new location information that differssignificantly from the user's previous location could have high-value.

The content definition could also be adjusted according to an urgencyassigned to certain user data. In one aspect, each piece of user data isassigned an urgency. The urgency could be based on the information'srelationship with an upcoming event, task, or other active scenario witha short timeframe. The perceived importance of the task or event canalso be a factor in the urgency as described subsequently. But as anexample, information about an unimportant event occurring in the nearfuture may be deemed non-urgent.

Having briefly described an overview of aspects of the technologydescribed herein, an exemplary operating environment in which aspects ofthe technology described herein may be implemented is described below inorder to provide a general context for various aspects. Referring to thefigures in general and initially to FIG. 1 in particular, an exemplaryoperating environment for implementing technology described herein isshown and designated generally as exemplary operating environment 100.The exemplary operating environment 100 is but one example of a suitablecomputing environment and is not intended to suggest any limitation asto the scope of use or functionality of aspects of the technologydescribed herein. Neither should the exemplary operating environment 100be interpreted as having any dependency or requirement relating to anyone component nor any combination of components illustrated.

Turning now to FIG. 1, a block diagram is provided showing an exampleoperating environment 100 in which some aspects of the presentdisclosure may be employed. It should be understood that this and otherarrangements described herein are set forth only as examples. Otherarrangements and elements (e.g., machines, interfaces, functions,orders, and groupings of functions, etc.) can be used in addition to orinstead of those shown, and some elements may be omitted altogether forthe sake of clarity. Further, many of the elements described herein arefunctional entities that may be implemented as discrete or distributedcomponents or in conjunction with other components, and in any suitablecombination and location. Various functions described herein as beingperformed by one or more entities may be carried out by hardware,firmware, and/or software. For instance, some functions may be carriedout by a processor executing instructions stored in memory.

Among other components not shown, example operating environment 100includes a number of user devices, such as user devices 102 a and 102 bthrough 102 n; a number of data sources, such as data sources 104 a and104 b through 104 n; server 106; and network 110. It should beunderstood that environment 100 shown in FIG. 1 is an example of onesuitable operating environment. Each of the components shown in FIG. 1may be implemented via any type of computing device, such as computingdevice 600 described in connection to FIG. 6, for example. Thesecomponents may communicate with each other via network 110, which mayinclude, without limitation, one or more local area networks (LANs)and/or wide area networks (WANs). In exemplary implementations, network110 comprises the Internet and/or a cellular network, amongst any of avariety of possible public and/or private networks.

User devices 102 a and 102 b through 102 n can be client devices on theclient-side of operating environment 100, while server 106 can be on theserver-side of operating environment 100. The user devices canfacilitate the completion of tasks and make a record of user activities.The user activities can be a source of contextual data that may be usedby a service on server 106. Server 106 can comprise server-side softwaredesigned to work in conjunction with client-side software on userdevices 102 a and 102 b through 102 n so as to implement any combinationof the features and functionalities discussed in the present disclosure.For example, the server 106 a personal assistant application that worksin conjunction with a client-side application. The server 106 mayreceive activity records, such as physiological data, email data,calendar data, and location data, from the user devices. This divisionof operating environment 100 is provided to illustrate one example of asuitable environment, and there is no requirement for eachimplementation that any combination of server 106 and user devices 102 aand 102 b through 102 n remain as separate entities.

User devices 102 a and 102 b through 102 n may comprise any type ofcomputing device capable of use by a user. For example, in one aspect,user devices 102 a through 102 n may be the type of computing devicedescribed in relation to FIG. 6 herein. By way of example and notlimitation, a user device may be embodied as a personal computer (PC), alaptop computer, a mobile device, a smartphone, a tablet computer, asmart watch, a wearable computer, a fitness tracker, a virtual realityheadset, augmented reality glasses, a personal digital assistant (PDA),an MP3 player, a global positioning system (GPS) or device, a videoplayer, a handheld communications device, a gaming device or system, anentertainment system, a vehicle computer system, an embedded systemcontroller, a remote control, an appliance, a consumer electronicdevice, a workstation, or any combination of these delineated devices,or any other suitable device.

Data sources 104 a and 104 b through 104 n may comprise data sourcesand/or data systems, which are configured to make data available to anyof the various constituents of operating environment 100, or system 200described in connection to FIG. 2. (For example, in one aspect, one ormore data sources 104 a through 104 n provide (or make available foraccessing) user data to user-data collection component 261 of FIG. 2.)Data sources 104 a and 104 b through 104 n may be discrete from userdevices 102 a and 102 b through 102 n and server 106 or may beincorporated and/or integrated into at least one of those components. Inone aspect, one or more of data sources 104 a though 104 n comprise oneor more sensors, which may be integrated into or associated with one ormore of the user device(s) 102 a, 102 b, or 102 n or server 106.Examples of sensed user data made available by data sources 104 a though104 n are described further in connection to user-data collectioncomponent 261 of FIG. 2. The data sources 104 a though 104 n cancomprise a knowledge base that stores information about a venue, a user,an event, traffic information, weather information, social network data,including a social graph for a user, or other entity related to aparticular user action. The data sources 104 a though 104 n can compriseenterprise data, such as an organization chart, that can be used to helpunderstand relationships between people the user is corresponding with.

Operating environment 100 can be utilized to implement one or more ofthe components of system 200, described in FIG. 2, including componentsfor collecting user data, identifying urgent data, identifying variousongoing scenarios, inferring event patterns, make in-routine andout-of-routine decisions and ultimately determine what, if anycontextual information, to communicate at a point in time.

Referring now to FIG. 2, with FIG. 1, a block diagram is providedshowing aspects of an example computing system architecture suitable forimplementing an embodiment of the technology described herein anddesignated generally as system 200. System 200 represents only oneexample of a suitable computing system architecture. Other arrangementsand elements can be used in addition to or instead of those shown, andsome elements may be omitted altogether for the sake of clarity.Further, as with operating environment 100, many of the elementsdescribed herein are functional entities that may be implemented asdiscrete or distributed components or in conjunction with othercomponents, and in any suitable combination and location.

Example system 200 includes network 110, which is described inconnection to FIG. 1, and which communicatively couples components ofsystem 200 including client device 205 and user-experience component260. Client device 205 (including its components 211, 212, 213, 214,215, 216, 217, 218, 219, 220, 230, 231, 232, 240, 241, 242, 243, 244,245, 246, 247, 250, 251, 252, 253, 254, and 255) and user-experiencecomponent 260 (including its components 261, 262, 263, 264, and 265) maybe embodied as a set of compiled computer instructions or functions,program modules, computer software services, or an arrangement ofprocesses carried out on one or more computer systems, such as computingdevice 600 described in connection to FIG. 6, for example.

In one embodiment, the functions performed by components of system 200are associated with one or more personal assistant applications,services, or routines. In particular, such applications, services, orroutines may operate on one or more user devices (such as user device102 a), servers (such as server 106), may be distributed across one ormore user devices and servers, or be implemented in the cloud. Moreover,in some embodiments, these components of system 200 may be distributedacross a network, including one or more servers (such as server 106) andclient devices (such as user device 102 a), in the cloud, or may resideon a user device, such as user device 102 a. Moreover, these components,functions performed by these components, or services carried out bythese components may be implemented at appropriate abstraction layer(s)such as the operating system layer, application layer, hardware layer,etc., of the computing system(s). Alternatively, or in addition, thefunctionality of these components and/or the embodiments describedherein can be performed, at least in part, by one or more hardware logiccomponents. For example, and without limitation, illustrative types ofhardware logic components that can be used include Field-programmableGate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs),Application-specific Standard Products (ASSPs), System-on-a-chip systems(SOCs), Complex Programmable Logic Devices (CPLDs), etc. Additionally,although functionality is described herein with regards to specificcomponents shown in example system 200, it is contemplated that in someembodiments functionality of these components can be shared ordistributed across other components.

Aspects of the technology determine what user data 210 is shared withthe user-data collection component 261 and when it is shared. Theinformation could be shared with any other device, such as the user's PCor tablet. The user-experience component 260 is used as an example of adevice that could receive information from the client device 205.

The user data 210 can be collected by a personal assistant or some otherdata collection component on the client device 205. User data is onetype of contextual data. Exemplary user data 210 includes email data211, email metadata 212, location data 213, text message data 214,social network data 215, calendar data 216, application data 217, searchdata 218, browsing data 219, and purchase data 220. Aspects of thetechnology described herein are not limited for use with this data.Other contextual data, including data records derived from this datacould be shared. Drive data includes any data that is output from ananalysis of signal data to make an inference or direct observation abouta user's activities. For example, physiological data and location datacould be combined to infer that the user is exercising. As anotherexample, location data and purchase data could be combined to infer thatthe user is watching a particular movie at the present time in aspecific theater. Such inferences can be made on a client device andrecorded for transfer to other devices.

The email data 211 can include the text of emails received on the clientdevice to one or more applications. The emails could be associated withone or more user accounts. In addition, the other recipients and centerof the email can be identified in the email records. Other informationabout the email, such as the time sent and received can be included inthe email data 211.

The email metadata 212 can include information about the email records.The email metadata 212 can include snippets of email text that arerelevant for a particular purpose. For example, a heuristic or naturallanguage processing system could identify text within an email messagethat is relevant to one or more events the user is associated with. Thetext could also include requests of the user and promises made by theuser. Such requests and promises or commitments can be used to populatea shadow calendar, a task list, or otherwise generate event data for auser.

Location data 213 can be gathered by GPS or some other technology on theclient device 205. Location data 213 indicates where the user, or atleast the client device 205, is located.

The text message data 214 can comprise similar information as wasdescribed previously with reference to the email data 211 and the emailmetadata 212, except the text message data 214 is related to textmessages sent and received by the user. The text message data 214 caninclude the content of a text as well as sender and recipientinformation. As with emails, insights derived from analyzing a textmessage are a type of text message data.

The social network data 215 can include information about social postsmade to one or more social networks or platforms. The information caninclude information about social posts read by a user, received by auser from a follower, and a user's interactions with a social post. Forexample, the social network data can include likes, dislikes, forwards,and other interactions with social network data and social posts. Theaddition or subtraction of individuals from the user's social networkscan also be noted within the social network data 215.

The calendar data 216 can comprise information from one or more usercalendars, such as office calendars, personal calendars, social mediacalendars, or even calendars from family members or friends of the user,in some instances. Some embodiments of the invention may construct acomplementary or shadow calendar for a user. In particular, in suchembodiments, the complementary or shadow calendar maybe used fordetermining when an event will occur and whether information related tothe event may be urgent and/or important.

In an embodiment, the complementary calendar may be constructed basedupon sensor data associated with a user of the client device 205. Forexample, a social network profile (e.g., social network posts, socialnetwork messages, a user profile indicating hobbies or interest of theusers, etc.) may be evaluated to identify an activity of the user as aparticular sensor data. In another example, a context of the user'sdevice may be evaluated to identify an activity of the user as thesensor data (e.g., a device location may be indicative of the user goingto soccer practice at a soccer field on Tuesdays; a device locationcheck-in may be indicative of the user going out on a movie date onSundays (e.g., the user may check-in through a social network); aconnectivity state, such as Wi-Fi connectivity, may indicate that theuser is at home, in the office, or at a coffee shop; a charging state,such as a car charging state, may indicate that the user is currentlydriving; a vacation itinerary file on the device may indicate that theuser will be going on a vacation in a week; etc.).

It may be appreciated that, in some aspects, a wide variety ofinformation, such as temporal information and/or locational information,may be evaluated to identify sensor data and/or supplement sensor data(e.g., a user's primary calendar may be used to identify conflictsand/or verify activities derived from sensor data; sensor data may beevaluated against real-time data. such as traffic information, weather,or supplemental information, which may include information from theuser's social media accounts, family or friends social media accounts,email, news, and other user data (e.g. crowd-sourced data). In this way,the complementary calendar may be constructed with one or more entriesderived from sensor data (e.g., automatically generated entries basedupon inferred activities). In an embodiment, a complementary calendarmay be merged with one or more calendars (e.g., the user's primarycalendar, a family calendar, a social network calendar, etc.) to createa shadow calendar comprising at least some of the complementary calendar(e.g., automatically generated entries derived/inferred from sensordata) and at least some of the one or more calendars (e.g., user entriespopulated within the primary calendar by the user). As used herein,calendar data can be data taken from a complementary calendar or anactual user calendar.

The application data 217 can include information about the applicationsthe user is interacting with or has open. When available, informationreceived from or input to the various applications can also be includedin the application data 217. The application data 217 can include a listof media the user has consumed, such as songs listened to along withinformation about when the user listened to individual songs. In oneaspect, information about areas the user was viewing on a navigation ormap application can be included within the application data 217.

The search data 218 can include information entered into a search queryof a publicly available search engine. The results and interactions withthose results can also be included in the search data 218. The searchdata 218 can also include information requested through a searchfunction integrated into the client device 205. A personal assistant isone example of an application that has search functionality. In such acase, requests made of a personal assistant and answers provided inresponse to those requests could be included within the search data 218.

The browsing data 219 includes information about webpages the usernavigated to through one or more browser applications. In this sense,the browsing data 219 is a special case of the application data 217.

The purchase data 220 could reflect purchases made through applicationsor through one or more webpages. In one instance, the application is acredit card or other payment application associated with the clientdevice 205. For example, some client devices include technology thatallows people to pay for goods or services using the client device 205.

In order to determine what information should be shared and when itshould be shared, contextual information about the device can beaccessed. The device data store 230 collects contextual informationabout the device state and provides this information or makes theinformation available to the signal analysis component 240 in the signalcompaction component 250. The contextual device information can includewhich communication connections 231 are currently active. Exemplarycommunication connections include Wi-Fi connections, Bluetoothconnections, 3G, 4G, LTE, and other cellular connections. Various wiredconnections, such as Ethernet connection, could be detected.

The battery level data 232 provides an indication of how much charge isleft in the battery. The battery level data 232 can also include powerusage rates that can be used to calculate how much battery life remainsat the current usage rate. The battery level data 232 can be animportant constituent of the signal compaction decision. For example, ifa large amount of battery life remains and the user is expected to be ina location where the user can charge the client device 205 relativelysoon, then more data could be sent sooner. On the other hand, if theclient device 205 is running low on battery power and the user is notexpected to be at a location where the client device 205 can berecharged, then less data should be shared.

Other contextual device information, not shown, can include a runningtotal of the user's data quota. The running total can be daily, monthly,weekly, or some other unit. The plug-in status of the client device isanother example of contextual device information. The device is pluggedin when it is receiving power from an external source such as a poweroutlet in a home or vehicle. The device's location can be both usercontextual data and device contextual data. The applications currentlyrunning on the client device 205 is another example of contextual devicedata.

The signal analysis component 240 includes a group of submodules thateach analyze user data 210 and/or device data 230 to generate derivativedata. The signal analysis component 240 includes a routine component241, an event component 242 component, a user-benefit component 243, anurgency component 244, a device-context component 245, a user-contextcomponent 246, and a signal user-interface component 247. Each of thesecomponents can be thought of as layers that can analyze user data incombination with other information, such as a store records andestablished patterns to make determinations that can be fed into thesignal compaction component 250. When information is not available forone of the signal analysis component 240 to make a determination, thecompaction decision can be made without input from an individualcomponent layer.

The event component 242 can associate user data with one or more events,track upcoming events, and record previously completed events. Eventdata compiled by the event component 242 can be used by other componentsto make decisions. For example, an event pattern determined by ananalysis of similar features in reoccurring events could be used todetermine a routine.

The term “event” is used broadly herein to include communication events,which refers to nearly any communication received or initiated by acomputing device associated with a user including attemptedcommunications (e.g., missed calls), communication intended for theuser, initiated on behalf of the user, or available for the user. Theterm “event” may also refer to a reminder, task, announcement, or newsitem (including news relevant to the user such as local or regionalnews, weather, traffic, or social networking/social media information).Thus, by way of example and not limitation, events can includevoice/video calls; email; SMS text messages; instant messages;notifications; social media or social networking news items orcommunications (e.g., tweets, Facebook posts or “likes”, invitations,news feed items); news items relevant to the user; tasks that a usermight address or respond to; RSS feed items; website and/or blog posts,comments, or updates; calendar events, reminders, or notifications;meeting requests or invitations; in-application communications includinggame notifications and messages, including those from other players; orthe like. Some communication events may be associated with an entity(such as a contact or business, including in some instances the userhimself or herself) or with a class of entities (such as close friends,work colleagues, boss, family, business establishments visited by theuser, etc.).

User data may be received from a variety of sources where the data maybe available in a variety of formats and received from one or moresensors. As used herein, a sensor may include a function, routine,component, or combination thereof for sensing, detecting, or otherwiseobtaining information such as user data from a data source 104 a, andmay be embodied as hardware, software, or both. By way of example andnot limitation, user data may include data that is sensed or determinedfrom one or more sensors (referred to herein as sensor data), such aslocation information of mobile device(s), smartphone data (such as phonestate, charging data, date/time, or other information derived from asmartphone), user-activity information (for example: app usage; onlineactivity; searches; voice data such as automatic speech recognition;activity logs; communications data including calls, texts, instantmessages, and emails; website posts; other user-data associated withevents; etc.) including user activity that occurs over more than oneuser device, user history, session logs, application data, contactsdata, calendar and schedule data, notification data, social-networkdata, news (including popular or trending items on search engines orsocial networks), online gaming data, ecommerce activity (including datafrom online accounts such as Amazon.com®, eBay®, PayPal®, or XboxLive®), user-account(s) data (which may include data from userpreferences or settings associated with a personal assistant applicationor service), home-sensor data, appliance data, global positioning system(GPS) data, vehicle signal data, traffic data, weather data (includingforecasts), wearable device data, other user device data (which mayinclude device settings, profiles, network connections such as Wi-Finetwork data, or configuration data, data regarding the model number,firmware, or equipment, device pairings, such as where a user has amobile phone paired with a Bluetooth headset, for example), gyroscopedata, accelerometer data, payment or credit card usage data (which mayinclude information from a user's PayPal account), purchase history data(such as information from a user's Amazon.com or eBay account), othersensor data that may be sensed or otherwise detected by a sensor (orother detector) component including data derived from a sensor componentassociated with the user (including location, motion, orientation,position, user-access, user-activity, network-access,user-device-charging, or other data that is capable of being provided byone or more sensor component), data derived based on other data (forexample, location data that can be derived from Wi-Fi, Cellular network,or IP address data), and nearly any other source of data that may besensed or determined as described herein. In some respects, user datamay be provided in user signals. A user signal can be a feed of userdata from a corresponding data source. For example, a user signal couldbe from a smartphone, a home-sensor device, a GPS device (e.g., forlocation coordinates), a vehicle-sensor device, a wearable device, auser device, a gyroscope sensor, an accelerometer sensor, a calendarservice, an email account, a credit card account, or other data sources.

The event component 242 is generally responsible for monitoring eventsand related information in order to determine event patterns, eventresponse information, and contextual information associated with events.For example, events and user responses to those events may be determinedby monitoring user data, and from this, event patterns may be determinedand unaddressed events detected.

In some embodiments, event component 242 may determine interpretive datafrom received user data. Interpretive data corresponds to data utilizedby the event component 242 to interpret user data. For example,interpretive data can be used to provide context to user data, which cansupport determinations or inferences made by the subcomponents.Moreover, it is contemplated that event component 242 may use user dataand/or user data in combination with interpretive data for carrying outthe objectives of the subcomponents described herein.

The event component 242, in general, is responsible for determiningevent patterns. In some embodiments, event patterns may be determined bymonitoring one or more variables related to events or user responses tothose events. These monitored variables may be determined from the userdata (for example: location, time/day, the initiator(s) or recipient(s)of a communication, the communication type (e.g., call, email, text,etc.), user device data, etc.). In particular, the variables may bedetermined from contextual data related to events. Thus, the variablescan represent context similarities among multiple events. In this way,patterns may be identified by detecting variables in common overmultiple events. More specifically, variables associated with a firstevent may be correlated with variables of a second event to identifyin-common variables for determining a likely pattern. For example, wherea first event comprises a user-initiated call to a contact identified as“mom” on Saturday and a second event comprises a user-initiated call tothe same contact (“mom”) on the following Saturday, a pattern may bedetermined that the user calls “mom” on Saturday. In this case, thein-common variables for the two events include the same contact-entity(mom), the same day (Saturday), that the communication wasuser-initiated, the same recipient of the communication (mom), and thesame type or mode of communication (a call).

An identified pattern becomes stronger (i.e., more likely or morepredictable) the more often the event instances that make up the patternare repeated. Similarly, specific variables can become more stronglyassociated with a pattern as they are repeated. For example, supposeevery day after 5 pm (after work) and while driving, a user callssomeone in the same group of contacts (which could be her familymembers). While the specific person called varies (i.e., thecontact-entity that the user calls), an event pattern exists because theuser repeatedly calls someone in this group.

Event patterns do not necessarily include the same communication modes.For instance, one pattern may be that a user calls or emails his momevery Saturday. Moreover, in some instances, events pattern may evolve,such as where the user who calls his mom every Saturday starts to emailhis mom instead of calling her on some Saturdays, in which case thepattern becomes the user communicating with his mom on Saturdays. Eventpatterns may include event-related routines; typical user activityassociated with events, or repeated event-related user activity that isassociated with at least one in-common variable. For example, aparticular user has a pattern of calling while driving but only after5:30 pm or when the drive lasts longer than 10 minutes. Or a user islikely to browse the Internet and respond to personal email between 7:00and 9:30 PM, but rarely after 9:30 PM. Further, in some embodiments,event patterns can include user response patterns to events.

Response information is determined by analyzing user data correspondingto events and user activity that occurs after a user becomes aware of anevent, including after the user becomes aware of an unaddressed event(such as a missed call). The event component 242 analyzes thisinformation in conjunction with the monitored event and determines a setof response information for the event. Based on response informationdetermined over multiple events, the event component 242 can determineresponse patterns of particular users for certain events, based oncontextual information associated with the event. The response to anevent can be used to determine its urgency or importance to a user. Forexample, where monitored events include incoming emails from a user'sboss, event component 242 may determine that the user responds to theemail at the first available opportunity after the user becomes aware ofthe email. But where the monitored event includes a missed call from theuser's wife, event component 242 may determine that the user typicallyreturns her calls between 12 pm and 1 pm (i.e., at lunch) or after 5:30pm (i.e., after work). Similarly, event component 242 may determine thata user responds to certain events only under certain conditions, such aswhen the user is at home, at work, in the car, in front of a computer,etc. In this way, event component 242 determines response informationthat incudes user response patterns for particular events.

Moreover, most users behave or react differently to different contactsor entities. Events, such as a meeting or birthday party, may beassociated with an entity or with a class of entities (e.g., closefriends, work colleagues, boss, family, businesses frequented by theuser such as a bank, etc.). Using contextual information, eventcomponent 242 may infer user response information for a user based onhow that user responded to similar classes of entities, or how otherusers responded in similar circumstances (such as where in-commonvariables are present). Thus, for example, where a particular userreceives a missed call from a new manager and has never responded tothat manager before, event component 242 can consider how that user haspreviously responded to his other managers or how the user's colleagues(as other users in similar circumstances) have responded to that samemanager or other managers.

The routine component 241 can determine whether the user is currentlyfollowing an established routine or is outside of an establishedroutine. A user routine, or a routine of a user, can correspond torecurring actions, or behavior patterns, of a user. In this respect, aroutine may be defined in terms of one or more events that make up theroutine. The routine component 241 can also be capable of determining orestablishing routines in the first place. A determination of whether theuser is currently following a routine can be communicated to the signalcompaction component 250 for use in a model that determines whether theuser data should be communicated. Also, services provided by the serviceprovider can be tailored to out of routine events. Accordingly,information related to out of routine events may be more urgent thaninformation related to routine events.

In certain respects, the present disclosure provides for the detectionand tracking of one or more instances of events with respect to users,as described previously. The detected events can be analyzed withrespect to one or more routines. For example, a routine may beidentified as corresponding to a user based on patterns formed bydetected events that make up the routine.

The routine component 241 can identify divergence between users and oneor more routines of the users. A divergence between a user and a routineof the user may be identified by determining that one or more eventsthat make up the routine are out of routine events. In some cases, anevent may be out of routine for a routine where it is determined that auser will diverge from, has diverged from, or may diverge from the eventwith respect to the routine. In this regard, a divergence can correspondto a departure from a modeled pattern of detected events that form aroutine.

In certain respects, routines may be analyzed based on accumulated userdata that can indicate the occurrence of one or more instances routineevents. Accumulated user data can comprise a collection of data thatcorresponds to a user. The user data may be continuously collected overtime by a large variety of possible data sources and/or data systemsthat in aggregate forms a detailed record of patterns of user actions,that correspond to one or more routines of the user. These routines ofthe user can be identified, extracted, and/or analyzed from theaccumulated user data at a level of scope, accuracy, and quantity thatotherwise would not be achievable by the user alone.

The user benefit component 243 can make the determination whether one ormore services provided by the user-experience component 260 would have abenefit to the user in the near future. The user benefit component 243can assign a benefit score to one or more available services at thepresent time. The score for available services can change as the usercontext changes. The user benefit component 243 can take user data asinput along with the user profile, record of upcoming events, and userroutines. For example, a user that is driving through a shoppingdistrict may benefit from a task reminder function provided by theuser-experience component 260 where the user typically has taskreminders related to shopping. Conversely, the same user sitting at workmight not benefit from a task reminder related to shopping. The userbenefit can take the urgency determination made by urgency component 244into account.

The urgency component 244 can evaluate the user context and assign anurgency score to one or more pieces of user data that has not yet beenshared with the user-experience component 260. Different pieces ofinformation can have a different urgency. The urgency can be related toknown services provided by the user experience. For example, if theuser-experience component 260 provides services related to upcomingmeetings and events then information received about an upcoming eventthat will occur in the near future, for example, in the next 20 minutes,might be urgent. The same information received a day in advance of theevent may receive less urgency. The urgency score can be calculatedbased on the amount of time between a time when the urgency score isbeing calculated and an event that is related to user data is scheduledto occur. The urgency score can take into account the importance of theevent to the user. For example, a regularly scheduled work meeting thatthe user typically attends could contribute to a higher urgency scorethan a regularly scheduled work meeting that the user typically skips.

The importance of a portion of user information can be based on an eventthe information is associated with. Accordingly, the importance of anevent may be determined to determine how urgent it is that informationabout the event be shared with a service provider. An importance levelcan indicate how important or imperative it is that a user addresses anevent, while an urgency level may indicate how soon the event should beaddressed. Some aspects of urgency component 244 may determine urgency,importance, or both. Moreover, a scheduled event may become more urgentas a deadline approaches, such as an anniversary, and the importancelevel and/or urgency level may be updated based on changes detected incontextual information, current user data, the user's response, newlydetected user patterns, or new unaddressed events that are determined tobe related to an already outstanding event. For example, a missed callfrom a boss following an unresponded-to email may indicate a higherurgency level for responding to the email.

In some embodiments, urgency component 244 determines an urgency leveland/or importance level (which may be embodied as a score or numericalvalue) using information about the unaddressed event, which may bereceived from event component 242, along with user data or contextualinformation. For example, urgency component 244 may consider similarunaddressed events and their frequency (such as repeated missed calls oran unresponded-to email and missed call from the same contact); previousresponses to similar events from the user or other users, which mayindicate a level of importance or urgency, based on how soon after thesimilar unaddressed event occurred the user(s) responded; or patterninformation such as whether the unaddressed event is associated with apattern or whether it is unexpected.

In some embodiments, the urgency level or importance level may bedetermined from contextual information based on context featuresassociated with the unaddressed event (including extracted keywords orother context features extracted from similar events). In particular, asdescribed previously, keywords and other context features may beextracted to determine information about user responses for one or moreusers, such as information about how users typically respond (includinghow quickly they respond), based on certain keywords or other contextfeatures associated with the event. Additionally some keywords may bepredetermined to indicate possible urgency (such as “urgent,”“immediate,” or similar words that may be present in communications).

In some embodiments, using the received information described in thepreceding two paragraphs, a degree of urgency or importance may bedetermined for an event and used for determining a value representingthe level of urgency or importance. For example, in an embodiment, thelevel of importance or urgency for an event may be determined relativeto previous responses of the user or similar responses of other users,including handling events previously determined to be urgent orimportant or previously determined to be unimportant or not urgent. Inthis way, the determined level may span a range (such as 1 to 10 or “NotUrgent” to “Extremely Urgent,” for example) based on a comparison tosimilar events and the extremes (urgent/important events and noturgent/important events) and how those events were handled. Further, insome embodiments, one or more thresholds may be applied for determiningwhether the determined urgency level value or importance level value issufficient to result in communicating information about the event. Forexample, a user may desire not to be bothered by notifications (e.g., anexemplary service that could be provided by a service provider, such asuser-experience component 260) corresponding to unaddressed eventshaving low importance (such as a missed call from a random salesperson).Moreover, the threshold values may vary based on the device context anduser context.

In some embodiments, an urgency level or importance level has anassociated probability or confidence indicating a likelihood of thedetermined urgency or importance. The confidence may be determined basedon the amount of contextual information potentially indicating urgencyor importance and/or the magnitude (or weight) associated with specificpieces of contextual information. (For example, an email from the user'sboss that is designated as a “high importance” message would have moreweight than an email from the boss with normal importance.) In someembodiments, the confidence may be used for prioritizing communicationof certain user data to a service.

The device-context component 245 can evaluate the device data 230 andassign a predefined device context profile that may be of use to thesignal compaction component 250 or other components. Various devicecontext profiles can be defined based on device variables that can helpdetermine whether computer resources used to communicate user data arecurrently scarce. Scare resources can include data transferavailability, which can be related to the device's current connections(e.g., Wi-Fi, Ethernet, Data Plan) and power availability (e.g., pluggedin or on battery, as well as available batter if on battery power). Forexample, the device could be assigned a context profile with unlimitedpower and unlimited bandwidth because the device is plugged into a powersource and connected to a Wi-Fi network that does not have a data quota.

In general, device context profiles can be based on the presence orabsence of a data quota and availability of power. On the one end, thecontext profile could indicate unlimited data transfer capability andunlimited power, as mentioned above. On the other end of the spectrum,the context profile could indicate very limited power and limited datatransfer. In between, both power and data transfer availability can bemeasured on a scale. The power availability can be based on batterycharge level if the device is not plugged in. The data transferavailability can be measured on a scale based on an amount of data leftin the user's data quota. Other factors, such as the amount of activeapplications, which applications are active, device location, overalldevice power usage rate, estimated battery life as measured in a unit oftime, could in isolation or combination be used to define a devicecontext profile.

The user-context component 246 can analyze user data 210 along withother information to assign one or more user context profiles to theuser given the current situation. The profiles can be thought of as asummary or conclusion based on the analysis of the user data, includingchanges over time. For example, the user data could show that the useris changing location at roughly 35 mph along the road. The device datacould also indicate that the client device 205 has established aBluetooth connection with the user's car. The user-context component 246could then assign a user to context profile for “driving an automobile.”The context profile can describe a broad activity and also have fieldsfor more specific information about the activity. In this example, the“driving profile” could also include a proposed destination, estimatedarrival time, and such. For example, a specific information could be adestination of the user's work place. Each field in the user contextprofile can have one or more variables that can be assigned with varyinglevels of confidence. Alternatively, various fields in a labeler contexttemplate can either be filled or left blank. The slots can be filledwhen the user data in combination with other information meets acriteria associated with a user context profile.

The signal user interface component 247 can provide an interface throughwhich a user can see what types of user data has been shared or will beshared. The user can express preferences regarding what type of data canbe shared. The user can also express a preference for one or more userexperiences that can be used to determine the urgency of various typesof user data in various scenarios. For example, user data that onlyenables a service the user is not interested in may be de-prioritized.In one aspect, the user can allocate a data quota to the sharing of userdata with the user-experience component 260 on a connection with limitedusage, such as a connection that is part of a data plan. This quota canbe different from the quota available in the data plan. Thisuser-defined quota can be used to determine whether information shouldbe communicated at a given point in time.

The signal compaction component 250 determines what user data should beshared at a particular point in time, if any. The signal compactioncomponent 250 can utilize one or more models that can be activated basedon scenarios to analyze available user data and determine whetherinformation should be shared at a point in time. If information is notshared at a first point in time, it may be held until a more appropriatetime for sharing, such as when the user is plugged into a power sourceand connected to a network that does not have a data quota. The signalcompaction component 250 includes a scenario component 252, a modelstore 253, a model selection component 254, and model executioncomponent 255.

The scenario component 252 analyzes the user data 210, the device data230, and outputs from the various components of the signal analysiscomponent 240 to determine whether one or more user scenarios iscurrently applicable. The user scenarios can be matched to differentmodels in the model store 253. The scenario can be passed to the modelselection component 254, which in turn selects a model for execution bythe model execution component 255. The various scenarios can include anin-routine scenario, an out of routine scenario, traveling on businessscenario, a traveling on pleasure scenario, a late for an upcoming eventscenario, a planning an event (e.g., travel, shopping, dining,entertainment), a commute scenario and such.

The scenario component 252 can use a classification system to assign theuser to one or more scenarios. The classification system can be trainedusing labeled user data, device data, and signal analysis data that mapsthe data to a scenario. The classification system can then use user data210, device data 230, and signal analysis data to assign the user to ascenario at a given point in time. In some instances, the user may notfall into any established scenarios. Even in routine and out of routinescenarios need not be binary. The user data could be ambiguous as towhether the user is clearly out of routine or in routine with minorvariations. This can be the case where few signals are available foranalysis.

The scenario component 252 can also use various heuristics to determinewhen the scenario is active. The heuristics define one or more variablesthat when present can positively contribute towards a determination thata scenario is active or conversely that a scenario is not active. Thevariables in a heuristic may be given different weights so that somevariables play a larger role in determining whether a scenario isongoing.

The model execution component 255 executes a selected model to determinewhether data should be shared at a given point in time. The modelexecution component 255 can use machine learning models to make thisdetermination. Heuristic models can also be used. The model executioncomponent 255 can take any available user data 210, device data 230, andsignal analysis data along with user profile data to determine whetherinformation should be shared. The goal of the model is to balance theimportance and urgency of the various piece of information against acost of using scarce resources to communicate the information.

In one heuristic approach, the model starts with a default frequency ofuser data communication and a default content definition. The contentdefinition defines what or how much user data will be communicated. Thecontent definition can be adjusted to communicate less information, forexample only urgent information. The first step can be to determine adevice context profile, as described previously. With some contextdevice profiles, no change is made to the default frequency or contentdefinition. With other contexts, the frequency is reduced and contentdefinition changed. For example, when the battery is running low thesharing frequency may be reduced. With still other device contextprofiles the frequency of transmission or amount of data could beincreased, for example when the user device is plugged into a poweroutlet and connected to transmission means with no data quota. Asdescribed subsequently, the amount of adjustment could vary depending onan active model. For example, the change in frequency could differbetween the regular model and a scenario-specific model.

The second step can be to determine a user context profile and adjustthe frequency and content definition for data to be sent. Theadjustments made based on user context can be made to whatever frequencyand content definition was determined appropriate based on the devicecontext. Thus, the default rate could be adjusted or an already adjustedrate could be further adjusted. In one aspect, the adjustment is apercentage increase or decrease. In another aspect, the adjustment issetting the frequency and content definition according to a presetfrequency without regard to the previous default frequency or contentdefinition.

The model can also determine the granularity with which informationshould be shared by adjusting the content definition. For example, whenthe user is in a “late for an event” scenario location information maybe deemed very important and urgent. Thus, the content definition in the“late for event” scenario can prioritize transmission of locationcontent over other types of contextual data. Additionally, email or textcorrespondence related to the event could also be important. However,given a scarcity of resources as indicated by limited battery power ordata quota the model may choose to show an average location periodicallyrather than each location data point. Similarly, snippets of relevantcorrespondence or other derivative information taken from thecorrespondence may be shared rather than the entire correspondence. Thecontent shared is defined by the active content definition.

The model can also determine how frequently the signal compactioncomponent 250 makes an evaluation regarding what data to share. Forexample, when a user is following a routine where available userexperiences are not typically needed for a period of time (e.g., theuser is asleep or at work), then the model can set the nextdetermination to be triggered based on the routine component 241 makinga determination that the user is out of routine. Alternatively, thesignal compaction component 250 could suggest a new determination bemade within a threshold period of time of the user attending the currentportion of the routine where user experiences are not likely to beneeded.

The model may be set to default frequency of transmission and a defaultamount of transmission. The default frequency of data transmission couldbe twice an hour. As the model determines an urgent use for data may bepresent, then the frequency could increase. Similarly, the amount ortypes of user data transmitted could start with a default. The modelcould determine that less data should be transmitted based on a limitedamount of data in a data quota or some other device context. In the casewhere limited data is to be sent, the model can determine that onlyinformation related to service with an urgent need is communicated.

Continuing with FIG. 2, user-data collection component 261 is generallyresponsible for accessing or receiving (and in some cases alsoidentifying) user data from one or more data sources, such as datasources 104 a and 104 b through 104 n of FIG. 1. In some embodiments,user-data collection component 261 may be employed to facilitate theaccumulation of user data of a particular user (or in some cases, aplurality of users including crowd-sourced data) for experiencecomponent 264, which provides one or more services to a user. The datamay be received (or accessed), and optionally accumulated, reformattedand/or combined, by data collection component 261 and stored in one ormore data stores, where it may be available to other components ofsystem 200. For example, the user data may be stored in or associatedwith a user profile 265, as described herein. In some embodiments, anypersonally identifying data (i.e. user data that specifically identifiesparticular users) is either not uploaded or otherwise provided from theone or more data sources with user data, is not permanently stored,and/or is not made available to various services.

In some respects, user data may be provided in user-data streams orsignals. A “user signal” can be a feed or stream of user data from acorresponding data source. For example, a user signal could be from asmartphone, a home-sensor device, a GPS device (e.g., for locationcoordinates), a vehicle-sensor device, a wearable device, a user device,a gyroscope sensor, an accelerometer sensor, a calendar service, anemail account, a credit card account, or other data sources. In someembodiments, user-data collection component 261 receives or accessesdata continuously, periodically, or as needed.

Features extractor 262 is generally responsible for determiningevent-related features (or variables) associated with an event that maybe used for identifying patterns of user events that can form routines.Event features may be determined from information about an event and/orfrom related contextual information. In some embodiments, featuresextractor 262 receives user data and analyzes the received informationto determine a set of zero or more features associated with an event.Common features for different events can be used to help establish anevent pattern.

The user model 263 can analyze user data and update the user profile 265with changes that result from new data. The profile information caninclude user interests, user relations, a home location, a worklocation, account information, social relationships, familyrelationships, work relationships, and such. The user profile caninclude event records, event patterns, responses to user services, andother information related to user preferences to receive services in agiven context.

The experience component 265 can provide one or more experiences basedon contextual information provided by the client device. The experiencescan help users complete tasks by providing reminders, providingdirections, providing suggestions, or similar.

Turning now to FIG. 3, a method 300 of signal compaction is providedaccording to an aspect of the present technology. The method 300 can beperformed by a client device to determine how frequently and what userdata may be transmitted from the client device to another device, suchas a user-experience component. In one aspect, the user-experiencecomponent is a personal assistant server.

At step 310, a device context for a client device is determined byevaluating device characteristics. The device context and relevantdevice characteristics have been described previously with reference tothe FIG. 2. The device context could be assigned a profile defined byvarious device characteristics. For example, a series of profiles may berelevant when the client device is running on battery power. Differentprofiles can be based on different levels of energy remaining in thebattery. Another set of profiles, could be based on whether an activedata link over which user data will be transmitted has a data quota.More granular profiles could be based on an amount of data left in thequota. As an example, when a device context profile that is associatedwith a reduced frequency of transmission is active, the defaultfrequency of user data transmission will be reduced to what can bedescribed as a device-context-specific transmission rate. The contentdefinition could be adjusted in a similar fashion to transmit lesscontent with each transmission. The definition is adjusted to make surethe most important or urgent user data is transmitted.

At step 312, a default user-data transmission frequency is adjustedaccording to the device context to generate a device-context-sensitivetransmission frequency. For example, the default frequency of two timesan hour could be adjusted to once an hour. The default frequency may bedecreased when computing resources on the client device are scarce.Exemplary computing resources include battery power in available datatransmission. The device-context sensitive transmission frequency onlytakes device context into account. For example, all else being equal,the device-context sensitive transmission frequency could be reducedwhen the battery power is low or a data quota is imposed on a device.

At step 314, a user context is determined for a user of the clientdevice. The user context and relevant device characteristics have beendescribed previously with reference to the FIG. 2. As an example, a usercontext could indicate that the user is out of routine. When the user isout of routine, one or more services enabled by the provision of userdata could be of significant benefit to the user. As with the devicecontext, user data can be evaluated to assign a user context profile tothe user at a point in time. The profile can dictate whether the activetransmission frequency is increased or decreased. The increase ordecrease can be by a discrete amount or percentage.

At step 316, the device-context-sensitive transmission frequency isadjusted according to the user context to generate auser-context-sensitive transmission frequency. For example, thefrequency could be adjusted from one to have an hour to four times anhour.

At step 318, user data is transmitted to a service at theuser-context-sensitive transmission frequency.

Turning now to FIG. 4, a method 400 of signal compaction is providedaccording to an aspect of the present technology. The method 400 can beperformed by a client device to determine how frequently and what userdata may be transmitted from the client device to another device, suchas a user-experience component. In one aspect, the user-experiencecomponent is a personal assistant server.

At step 410, user context data is analyzed on a client device todetermine that a scenario-specific model should be used to determine afrequency with which user data is transmitted. Various heuristics can beused to determine when a scenario is active. The heuristics define oneor more variables that indicate that a scenario is active or converselythat a scenario is not active. The variables in a heuristic may be givendifferent weights so that some variables play a larger role indetermining whether a scenario is ongoing. The various scenarios caninclude an in-routine scenario, an out of routine scenario, traveling onbusiness scenario, a traveling on pleasure scenario, a late for anupcoming event scenario, a planning an event (e.g., travel, shopping,dining, entertainment), a commute scenario and such.

At step 412, a user context is determined for a user of the clientdevice. The user context and relevant device characteristics have beendescribed previously with reference to the FIG. 2. As an example, a usercontext could indicate that the user is out of routine. When the user isout of routine, one or more services enabled by the provision of userdata could be of significant benefit to the user. As with the devicecontext, user data can be evaluated to assign a user context profile tothe user at a point in time. The profile can dictate whether the activetransmission frequency is increased or decreased. The increase ordecrease can be by a discrete amount or percentage.

At step 414, a user-context-sensitive transmission frequency isdetermined according to the scenario-specific model. The transmissionfrequency determined according to the scenario specific model can differfrom the frequency determined by a normal or default model.

At step 416, user data is transmitted to a service at theuser-context-sensitive transmission frequency.

Turning now to FIG. 5, a method 500 of signal compaction is providedaccording to an aspect of the present technology. The method 500 can beperformed by a client device to determine how frequently and what userdata may be transmitted from the client device to another device, suchas a user-experience component. In one aspect, the user-experiencecomponent is a personal assistant server.

At step 510, a user context for a user of the client device isdetermined. The user context and relevant device characteristics havebeen described previously with reference to the FIG. 2.

At step 512, a scenario-specific model is selected to be used based onthe user context. Various heuristics can be used to determine when ascenario is active. The heuristics define one or more variables thatindicate that a scenario is active or conversely that a scenario is notactive. The variables in a heuristic may be given different weights sothat some variables play a larger role in determining whether a scenariois ongoing. The various scenarios can include an in-routine scenario, anout of routine scenario, traveling on business scenario, a traveling onpleasure scenario, a late for an upcoming event scenario, a planning anevent (e.g., travel, shopping, dining, entertainment), a commutescenario and such.

At step 514, a device context is determined for a client device byevaluating device characteristics. The device context and relevantdevice characteristics have been described previously with reference tothe FIG. 2.

At step 516, a default user-data transmission frequency is adjusted byan amount specific to the scenario-specific model according to thedevice context to generate a device-context-sensitive transmissionfrequency. The device-context-sensitive transmission frequency takesonly the device-context, such as battery charge, into account in view ofthe scenario-specific model, which prioritizes some transmissions overothers. Specifically, the scenario-specific model prioritizestransmissions of data that are relevant to the current scenario overdata that is not related. For example, during a navigation scenariolocation data may be prioritized over communications, unless thecommunications are related to the navigation.

At step 518, the device-context-sensitive transmission frequency isadjusted by an amount specific to the scenario-specific model accordingto the user context to generate a user-context-sensitive transmissionfrequency. The user-context-sensitive transmission frequency adjusts thedevice-context-sensitive transmission frequency upward or downward basedon user context. Thus, the user-context-sensitive transmission frequencytakes both the device context and user context into account along withthe active scenario.

At step 520, user data is transmitted to a service at theuser-context-sensitive transmission frequency.

Exemplary Operating Environment

Referring to the drawings in general, and initially to FIG. 6 inparticular, an exemplary operating environment for implementing aspectsof the technology described herein is shown and designated generally ascomputing device 600. Computing device 600 is but one example of asuitable computing environment and is not intended to suggest anylimitation as to the scope of use of the technology described herein.Neither should the computing device 600 be interpreted as having anydependency or requirement relating to any one or combination ofcomponents illustrated.

The technology described herein may be described in the general contextof computer code or machine-useable instructions, includingcomputer-executable instructions such as program components, beingexecuted by a computer or other machine, such as a personal dataassistant or other handheld device. Generally, program components,including routines, programs, objects, components, data structures, andthe like, refer to code that performs particular tasks or implementsparticular abstract data types. The technology described herein may bepracticed in a variety of system configurations, including handhelddevices, consumer electronics, general-purpose computers, specialtycomputing devices, etc. Aspects of the technology described herein mayalso be practiced in distributed computing environments where tasks areperformed by remote-processing devices that are linked through acommunications network.

With continued reference to FIG. 6, computing device 600 includes a bus610 that directly or indirectly couples the following devices: memory612, one or more processors 614, one or more presentation components616, input/output (I/O) ports 618, I/O components 620, and anillustrative power supply 622. Bus 610 represents what may be one ormore busses (such as an address bus, data bus, or a combinationthereof). Although the various blocks of FIG. 6 are shown with lines forthe sake of clarity, in reality, delineating various components is notso clear, and metaphorically, the lines would more accurately be greyand fuzzy. For example, one may consider a presentation component suchas a display device to be an I/O component. Also, processors havememory. The inventors hereof recognize that such is the nature of theart and reiterate that the diagram of FIG. 6 is merely illustrative ofan exemplary computing device that can be used in connection with one ormore aspects of the technology described herein. Distinction is not madebetween such categories as “workstation,” “server,” “laptop,” “handhelddevice,” etc., as all are contemplated within the scope of FIG. 6 andrefer to “computer” or “computing device.”

Computing device 600 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by computing device 600 and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable media may comprise computerstorage media and communication media. Computer storage media includesboth volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules, orother data.

Computer storage media includes RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical disk storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices. Computer storage media doesnot comprise a propagated data signal.

Communication media typically embodies computer-readable instructions,data structures, program modules, or other data in a modulated datasignal such as a carrier wave or other transport mechanism and includesany information delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared, and other wireless media. Combinations of any ofthe above should also be included within the scope of computer-readablemedia.

Memory 612 includes computer storage media in the form of volatileand/or nonvolatile memory. The memory 612 may be removable,non-removable, or a combination thereof. Exemplary memory includessolid-state memory, hard drives, optical-disc drives, etc. Computingdevice 600 includes one or more processors 614 that read data fromvarious entities such as bus 610, memory 612, or I/O components 620.Presentation component(s) 616 present data indications to a user orother device. Exemplary presentation components 616 include a displaydevice, speaker, printing component, vibrating component, etc. I/O ports618 allow computing device 600 to be logically coupled to other devices,including I/O components 620, some of which may be built in.

Illustrative I/O components include a microphone, joystick, game pad,satellite dish, scanner, printer, display device, wireless device, acontroller (such as a stylus, a keyboard, and a mouse), a natural userinterface (NUI), and the like. In aspects, a pen digitizer (not shown)and accompanying input instrument (also not shown but which may include,by way of example only, a pen or a stylus) are provided in order todigitally capture freehand user input. The connection between the pendigitizer and processor(s) 614 may be direct or via a coupling utilizinga serial port, parallel port, and/or other interface and/or system busknown in the art. Furthermore, the digitizer input component may be acomponent separated from an output component such as a display device,or in some aspects, the usable input area of a digitizer may coexistwith the display area of a display device, be integrated with thedisplay device, or may exist as a separate device overlaying orotherwise appended to a display device. Any and all such variations, andany combination thereof, are contemplated to be within the scope ofaspects of the technology described herein.

An NUI processes air gestures, voice, or other physiological inputsgenerated by a user. Appropriate NUI inputs may be interpreted as inkstrokes for presentation in association with the computing device 600.These requests may be transmitted to the appropriate network element forfurther processing. An NUI implements any combination of speechrecognition, touch and stylus recognition, facial recognition, biometricrecognition, gesture recognition both on screen and adjacent to thescreen, air gestures, head and eye tracking, and touch recognitionassociated with displays on the computing device 600. The computingdevice 600 may be equipped with depth cameras, such as stereoscopiccamera systems, infrared camera systems, RGB camera systems, andcombinations of these, for gesture detection and recognition.Additionally, the computing device 600 may be equipped withaccelerometers or gyroscopes that enable detection of motion. The outputof the accelerometers or gyroscopes may be provided to the display ofthe computing device 600 to render immersive augmented reality orvirtual reality.

A computing device may include a radio 624. The radio 624 transmits andreceives radio communications. The computing device may be a wirelessterminal adapted to receive communications and media over variouswireless networks. Computing device 600 may communicate via wirelessprotocols, such as code division multiple access (“CDMA”), global systemfor mobiles (“GSM”), or time division multiple access (“TDMA”), as wellas others, to communicate with other devices. The radio communicationsmay be a short-range connection, a long-range connection, or acombination of both a short-range and a long-range wirelesstelecommunications connection. When we refer to “short” and “long” typesof connections, we do not mean to refer to the spatial relation betweentwo devices. Instead, we are generally referring to short range and longrange as different categories, or types, of connections (i.e., a primaryconnection and a secondary connection). A short-range connection mayinclude a Wi-Fi® connection to a device (e.g., mobile hotspot) thatprovides access to a wireless communications network, such as a WLANconnection using the 802.11 protocol. A Bluetooth connection to anothercomputing device is a second example of a short-range connection. Along-range connection may include a connection using one or more ofCDMA, GPRS, GSM, TDMA, and 802.16 protocols.

The technology described herein has been described in relation toparticular aspects, which are intended in all respects to beillustrative rather than restrictive. While the technology describedherein is susceptible to various modifications and alternativeconstructions, certain illustrated aspects thereof are shown in thedrawings and have been described above in detail. It should beunderstood, however, that there is no intention to limit the technologydescribed herein to the specific forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructions,and equivalents falling within the spirit and scope of the technologydescribed herein.

1. A computing device comprising: a processor; and computer storagememory having computer-executable instructions stored thereon which,when executed by the processor, configure the computing device to:determine a device context for the computing device by evaluating devicecharacteristics; adjust a default user-data transmission frequencyaccording to the device context to generate a device-context-sensitivetransmission frequency; determine a user context for a user of thecomputing device; adjust the device-context-sensitive transmissionfrequency according to the user context to generate auser-context-sensitive transmission frequency; and transmit user data toa service at the user-context-sensitive transmission frequency.
 2. Thecomputing device of claim 1, wherein the computer-executableinstructions, when executed by the processor, configure the computingdevice to: determine the device context by evaluating whether thecomputing device is connected to an external power source; and determinethe device-context-sensitive transmission frequency based at least onwhether the computing device is connected to the external power source.3. The computing device of claim 1, wherein the computer-executableinstructions, when executed by the processor, configure the computingdevice to: determine the device context by evaluating an energy levelremaining in a battery of the computing device; and determine thedevice-context-sensitive transmission frequency based at least on theenergy level remaining in the battery of the computing device.
 4. Thecomputing device of claim 1, wherein the computer-executableinstructions, when executed by the processor, configure the computingdevice to: determine the device context by evaluating whether thecomputing device is will communicate the user data over a channel with adata quota; and determine the device-context-sensitive transmissionfrequency based at least on whether the computing device willcommunicate the user data over the channel with the data quota.
 5. Thecomputing device of claim 1, wherein the computer-executableinstructions, when executed by the processor, configure the computingdevice to: based at least on the device context, adjust a defaultcontent definition obtain an adjusted content definition; and select theuser data to transmit to the service according the adjusted contentdefinition, wherein the adjusted content definition excludes at leastsome other user data that is transmitted when the default contentdefinition is applicable.
 6. The computing device of claim 1, whereinthe user context indicates that the user is out-of-routine and theuser-context-sensitive transmission frequency is greater than thedevice-context-sensitive transmission frequency.
 7. The computing deviceof claim 1, wherein the user context indicates that the user has anupcoming event and the user-context-sensitive transmission frequency isgreater than the device-context-sensitive transmission frequency. 8-20.(canceled)
 21. A method performed by a computing device, the methodcomprising: determining a device context for the computing device byevaluating device characteristics; adjusting a default user-datatransmission frequency according to the device context to generate adevice-context-sensitive transmission frequency; determining a usercontext for a user of the computing device; adjusting thedevice-context-sensitive transmission frequency according to the usercontext to generate a user-context-sensitive transmission frequency; andtransmitting user data to a service at the user-context-sensitivetransmission frequency.
 22. The method of claim 21, further comprising:determining the device context by evaluating a power usage rate of thecomputing device and an expected remaining battery life of the computingdevice given the power usage rate; and determining thedevice-context-sensitive transmission frequency based at least on theexpected remaining battery life.
 23. The method of claim 21, furthercomprising: determining the device context by evaluating whether thecomputing device is expected to arrive at a charging location within aspecified amount of time; and determining the device-context-sensitivetransmission frequency based at least on whether the computing device isexpected to arrive at the charging location within the specified amountof time.
 24. The method of claim 21, further comprising: determining thedevice context by evaluating a running total of a data quota for thecomputing device; and determining the device-context-sensitivetransmission frequency based at least on the running total of the dataquota for the computing device.
 25. The method of claim 21, furthercomprising: determining the device context by identifying applicationsthat are active on the computing device; and determining thedevice-context-sensitive transmission frequency based at least on theapplications that are active on the computing device.
 26. The method ofclaim 21, further comprising: selecting a device context profile from aplurality of predefined device context profiles based at least on acurrent data transfer capability of the computing device; anddetermining the device-context-sensitive transmission frequency based atleast on the selected device context profile.
 27. The method of claim21, further comprising: selecting a device context profile from aplurality of predefined device context profiles based at least on acurrent availability of power to the computing device; and determiningthe device-context-sensitive transmission frequency based at least onthe selected device context profile.
 28. A hardware computer storagemedium comprising instructions embodied thereon which, when executed bya computing device, cause the computing device to perform actscomprising: determining a device context for the computing device byevaluating device characteristics; adjusting a default user-datatransmission frequency according to the device context to generate adevice-context-sensitive transmission frequency; determining a usercontext for a user of the computing device; adjusting thedevice-context-sensitive transmission frequency according to the usercontext to generate a user-context-sensitive transmission frequency; andtransmitting user data to a service at the user-context-sensitivetransmission frequency.
 29. The hardware computer storage medium ofclaim 28, the acts further comprising: determining the user contextbased at least on a communication by the user of the computing device;and determining the user-context-sensitive transmission frequency basedat least on the communication by the user.
 30. The hardware computerstorage medium of claim 29, the acts further comprising: derivinginformation from at least one of a calendar entry, an email, a textmessage, or a social network interaction by the user of the computingdevice; and determining the user-context-sensitive transmissionfrequency based at least on the information derived from the at leastone of the calendar entry, the email, the text message, or the socialnetwork interaction.
 31. The hardware computer storage medium of claim28, the acts further comprising: determining at least one task that theuser of the computing device is currently performing or has performedwithin a predefined time frame; and determining theuser-context-sensitive transmission frequency based at least on the atleast one task.
 32. The hardware computer storage medium of claim 28,the acts further comprising: determining at least one object that theuser of the computing device is currently engaging or has engaged withina predefined time frame; and determining the user-context-sensitivetransmission frequency based at least on the at least one object. 33.The hardware computer storage medium of claim 28, the acts furthercomprising: determining at least one physical characteristic of the userof the computing device; and determining the user-context-sensitivetransmission frequency based at least on the at least one physicalcharacteristic of the user.